Enterprises are increasingly securing their electronic assets using a variety of software architectures, machines, and software services. The problem is that the enterprises and their machines, assets, services, etc. evolve over time. So, newer machines and services may be used to piecemeal replace failing resources or even to expand the enterprise as needed. In other cases, improved security software services may be released within the industry, but the enterprise may only be capable of achieving spotty deployment based on legacy efforts needed for a full scale integration of the security services. In still other cases, some existing services may be upgraded and require newer software services while other existing services are incapable with the newer software services.
Quickly, even the best managed enterprise will devolve in time into a heterogeneous security environment in which disparate devices and services are managed by varying degrees of security. For example, an enterprise may have multiple security databases on multiple computers. Here, two or more computers may participate in secure transactions with one another, such that each software service on each computer requires access to private and public keys for the transactions to succeed. The storage and management of these keys are provided via the security databases. Many security databases are specific to a platform or execution environment in which they operate (e.g., Java Platform Enterprise Edition (J2EE), etc.). Administrators in these environments must maintain each security database on each separate computer with the proper key information required by the software services that use them, so that the distributed computing components can properly interact with one another.
As another example, various software services running on various different computers within a network may require different types of security databases for keys. Some common types include Java key stores, privacy-enhanced electronic mail (PEM), distinguished encoding rules (DER), etc. Security software services are designed to work with specific types of security databases. Thus, managing keys housed in different types of security databases results in using different key management tools, which are specific to certain execution environments and specific to certain security database types. Consequently, administrators operating under these circumstances must understand and be proficient in all the key management tools required to manage their different types of security databases. Moreover, keeping various security databases aligned and in synchronization with one another can be full of mind-numbing detail and also fraught with many opportunities to get just one thing wrong and thereby render the entire enterprise environment inoperable.
Essentially, security administrators are limited to working with only the set of keys in a single security database that can be managed through the key management tool that operates with that single security database. Therefore, a full inventory of keys within a network or enterprise may require running each of the available key management tools against each of the available security databases on each of the computers being managed. This complicates various tasks associated with key administration, such as: identifying and updating expiring certificates; generating keys and certificate signing requests (CSR's) for new keys that need to be signed by a certificate authority (CA); assigning keys to an appropriate security database; and migrating keys to different hardware (this may also unduly expose confidential information (private keys) on the network wire).
Thus, what is needed is a mechanism that allows for more efficient and flexible management of keys in heterogeneous environments.